Aspect-oriented Refactoring of Java Programs

Classes, which expresses the notion that implementation code in abstract classes should be moved to aspects, leaving room to turn the abstract class into a Java interface. Subclasses become free to inherit from some other class and the new interface can still acquire a default, concrete implementation thanks to the ability of AspectJ to emulate mixin composition. In addition, Monteiro and Fernandes analyse the refactorings proposed in prior publications (mentioned above) and propose corresponding code smells. In another publication (Monteiro & Fernandes, 2006b), the same authors argue that the use of a number of design patterns (Gamma et al., 1995) becomes likewise obsolete in light of AOP and suggests further work for deriving new refactorings through which pattern instances are replaced with aspects. Some suggestions for a few refactorings are provided, mentioning a name and short outline. Malta and Valente propose a number of OOP refactorings to complement the aforementioned collections (Malta & Valente, 2009). They note that a number of OOP refactorings need to be performed on existing OOP systems to adequately prepare them for the extraction of CCCs. Many CCCs take the form of a pattern in code that appears in multiple points of the system but often such patterns are placed in points not covered by the joinpoint models of current AOPLs and present irregularities among the various points, e.g., in the relative order of statements or in the position of a fragment within a method’s body (sometimes in the beginning, sometimes in the middle or in the end). The refactorings proposed by Malta and Valente aim to place such code patterns within the reach of the AOPL’s pointcuts and to produce the required regularity. The refactorings proposed are divided into groups for statement reordering and method extraction. Malta et al. complement that work with a set of guidelines to assist developers in the application of the refactorings (Malta et al., 2009). They also announce a prototype tool (TransformationMapper) providing partial support to developers in applying the guidelines. Though it uses neither refactorings nor code smells as a means of expression, the following work deserves to be mentioned. Griswold et al. propose a design rule in which an aspect is used to declare a special interface based on pointcuts, to create a layer between aspect modules and the concrete classes of the base system (Griswold et al., 2006). This kind of interface is named crosscut programming interface (XPI) and its purpose is to provide a stable contract on the basis of which both base programmers and aspect programmers can work independently. The idea of XPIs results from a study that showed that although aspects can very aggressively hide the details of their implementations to the remaining modules of a system, this encapsulation is one-sided (Sullivan et al., 2005). In many cases, the aspects themselves were extremely exposed to minute details of the remaining modules in the system. Apart from issues related to pointcut coding techniques, the refactoring space for AspectJ seems to have been explored to a reasonable extent already. The current body of knowledge can be used as a basis for developing refactoring catalogues tailored for other AOPLs. 5.2 Tool Support for Aspect-Oriented Refactoring The earliest works on tool support (Hanenberg et al., 2003, Hannemann et al., 2003, Hannemann et al., 2005, Binkley et al., 2005) are focused on the extraction of CCCs from existing Java systems. In common to many approaches on tool support is the recognition that the crosscutting nature of the concerns to be extracted places requirements that are hard to meet adequately when using the incremental approaches generally favoured in traditional OOP refactorings. Often, these comprise applying multiple transformation steps requiring knowledge of the system that is either local or clearly circumscribed. By contrast, the process of migrating OOP systems to AOP is more knowledge-intensive and any refactoring tool needs to involve the developer in a workflow. This also applies to the aspect aware versions of OOP refactorings: a given refactoring can affect multiple, scattered points in a system and the developer may need to deal with each case individually (Hanenberg et al., 2003, Hannemann et al., 2003, Wloka et al., 2008). Miguel P. Monteiro & João M. Fernandes Two approaches are focused on CCC extraction though none tackles the issue of the impact of the refactorings on existing pointcuts (Hannemann et al., 2005, Binkley et al., 2006). Hannemann et al. proposes an approach conceptually based on the notion of role as used in design patterns (Hannemann et al., 2005, Hannemann et al., 2003). The approach is likewise tailored for the migration of the implementation of a design pattern to an equivalent implementation in AspectJ, though it seems capable of being applied to other, more general cases of CCCs. It is based on a role-based abstract description of the target crosscutting structure, used to differentiate between individual concrete program elements. To perform a concrete refactoring, those elements must be mapped to the abstractions for the description at hand. One such abstract description must be developed for each pattern or crosscutting structure. The tool drives a workflow whose main purpose is to perform the mapping, comprising the following steps:  Selection: a developer selects a refactoring from the collection provided by the tool.  Mapping: a mapping of program elements to pattern roles is performed.  Configuration: static analysis is used to identify possible alternative decisions in the refactoring process. A number of issues may arise in this phase (e.g., name conflicts), in which the developer must make decisions for each case presented.  Execution: the tool performs the sequence of transformations on the basis of the abstract representation, configured and concretized with the developer’s inputs and decisions. Possible transformations include moving methods from classes to aspects, creation of new program elements and removal of existing elements. Note that this can have a direct impact on the program’s interface. Binkley et al. present an approach that similarly extracts a CCC into an aspect module and provide a tool called AOP-Migrator that implements the approach (Binkley et al., 2006). Unlike the approach by Hannemann et al., AOP-Migrator also performs aspect mining, using it to mark code regions that represent instances of the candidate elements to be extracted. Supported regions include whole methods, method calls and sequences of statements (i.e., blocks of code). The tool supports a small number of semi-automated refactorings that extract the marked fragments, which can be automatically migrated to aspects yielding a semantically equivalent AOP implementation of the program. As with the above approach, the tool drives a workflow, comprising a loop iterating over all the marked portions of code. In turn, each marked segment of code is analyzed in isolation and moved to an aspect after preparations made with the involvement of the developer. The iteration goes on until no more marked statements remain in the base code. The loop comprises the following steps:  Discovery: the tool determines the applicable refactorings for a marked code fragment.  Enabling transformation: In case a selected fragment cannot be extracted through existing refactorings, OOP refactorings transformations are suggested (e.g., Extract Method) to make an extraction into aspects generally feasible.  Selection: the selection of an appropriate refactoring is guided through a pre-set prioritization scheme that the developer can accept or override.  Execution: Fully automated generation of aspect template code, move of marked fragments to the aspect and creation of necessary pointcuts and advices. For every extracted program element it generates a single pointcut bound to a single advice which contains the extracted element. However, AOP-Migrator also supports AOP-specific refactorings named “pointcut abstraction" that aim at improving the quality of the automatically generated pointcut code, by unifying definitions shared by different generated elements. Aspect-oriented Refactoring of Java Programs Wloka et al. tackle a different work front than the one above, focusing on automating the detection of change effects on pointcuts and the generation of pointcut updates, i.e., supporting aspect aware refactorings (Wloka et al., 2008). This approach is based on a model for representing pointcuts, explaining the change impact analysis and introducing an approach for automating pointcut update decisions. A tool based on this model is presented – named SoothSayer – that performs program analysis to detect affected or broken pointcuts, assess ways to derive suitable pointcut adjustments and determine when developer feedback must be provided. Since all approaches have to cope with changes to the base system that may affect existing pointcuts, this work can be seen as complementing those previously mentioned. Anbalagan and Xie propose an automated approach for mining aspects and inferring pointcuts from legacy Java applications and present a prototype implementation (Anbalagan & Xie, 2007). The tool automatically identifies aspects and their joinpoints, clusters the join points based on common characteristics in the method names, using lexical matching, and infers a pointcut expression for each cluster of joinpoints. An additional testing mechanism checks that the inferred pointcut expressions are of correct strength. This work is differs from that by Wloka et al. in that it does not consider the maintenance of the pointcut when the base system undergoes some evolution. Piveta at al discuss representations of refactoring opportunities for AOP software suitable for automation tools and propose a set of representation mechanisms to provide a precise way to describe refactoring conditions, the association of conditions with refactorings and how to perform searches for refactoring opportunities (Piveta et al., 2009). 5.3 Refactoring Experiments involving the Aspect-Oriented Paradigm This sub-section covers case studies and refactoring experiments of various natures involving AOP. Note that the work surveyed in the previous sections also generally includes experiments but there the focus is not on the experiments themselves. Middleware seems to be the “killer application” of AOP and middleware systems feature prominently in refactoring experiments. Colyer and Clement describe an experiment in using AspectJ to refactor both homogeneous and heterogeneous concerns in a industrial middleware product-line platform (Colyer & Clement, 2004). They report having significantly more difficulty with heterogeneous concerns than with homogeneous concerns. Zhang and Jacobsen describe an analysis based on aspect mining of a CORBA-based middleware system that suggests that middleware architectures inherently suffer from having coordinate CCCs (Zhang & Jacobsen, 2003). They also report on the use of AspectJ to modularize system’s CCCs. A subsequent quantitative analysis based on software engineering metrics suggests that AOP lowers the complexity of the architecture, increases modularity and preserves performance. Marin et al. propose a general strategy to reengineer legacy OOP systems into aspect-oriented versions of those systems (Marin et al., 2009). The various phases of the strategy are driven by a classification of CCCs into crosscutting concern sorts proposed in an earlier work (Marin et al., 2005). Sorts are CCCs described by their specific symptoms (i.e., implementation idiom in a non-AOP language), and a (desired) aspect mechanism to modularize a sort instances with an AOP solution. The strategy covers the following phases:  Identification of the primary CCCs, using aspect mining techniques.  Concern exploration, in which the outputs from the previous phase are used to acquire a comprehensive identification of the implementation elements of the identified CCCs.  Query-based concern modelling and documentation, in which various modelling tools are used to obtain coherent representations of the CCCs under analysis. A classification of the CCCs into sorts is also performed in this phase. Miguel P. Monteiro & João M. Fernandes  Refactoring of the OOP idioms modelled and documented in the previous phases into equivalent AOP implementations. Marin et al. mention a number of tools to assist some of the phases but what comes to the fore is the strategy, which was tested with the JHotDraw open source project, yielding a version of JHotDraw in which a few CCCs were migrated to AspectJ aspects. That version was made publicly available as an open-source project called AJHotDraw (sourceforge.net/projects/ajhotdraw). However, the strategy was applied to JHotDraw without the tools. Kulesza et al. report on the use of refactorings from the catalogue by Monteiro and Fernandes to aspectize the JUnit framework (Kulesza et al., 2005, Monteiro & Fernandes, 2006a). Benn et al. report on an experiment in refactoring of a medium-scale distributed system to AspectJ. A suite of metrics for internal quality characteristics of the code is used to perform an assessment of the results, which suggests that the refactoring improved the internal quality of the subject system (Benn et al., 2005).